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DECLARATION UNDER 37 CF.R. § 1.131 

1. This declaration is to establish the status of the invention in the above-captioned U.S. patent 
application in the United States on May 30, 1996, which is the effective date of U.S. Patent No. 
5,815,652, entitled "COMPUTER MANAGEMENT SYSTEM", to Ote, et al. which was cited by 
the Examiner against the above-captioned application. 

2. We are the named joint inventors of the described subject matter and all claims in the 
above-referenced application. 

3. We have read the Office Action mailed December 13, 1999 (Paper No. 12) regarding the 
patent application. 

4. We developed our invention as described and claimed in the subject application in this 
country, and acted with due diligence to reduce the invention to practice from at least May 30, 
1996, as evidenced by the following events: 

a. By at least May 30, 1996, we had conceived of a method of reporting a system 
failure in a server system, the method comprising detecting a system failure condition, 
transmitting failure information related to the failure condition to an independently functional 
system recorder, storing the failure information related to the failure condition in a system log, 
and reporting an occurrence of the failure condition. 
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Our conception and subsequent inventive activity leading to at least a constructive 



reduction to practice of an embodiment of the present invention is evidenced by the following: 

c. By at least May 30, 1996, we had conceived of using a network of 
microcontrollers as the monitoring and control hardware of the subject invention. A document, 
entitled "Raptor Wire Service Architecture, Version 1.2" ("Wire Architecture"), was written at 
least as early as March 19, 1996, as evidenced by the document date. A copy of Wire 
Architecture is attached as Exhibit A. Wire Architecture describes detecting a system failure 
condition (CPU A and/or CPU B controller shown on figure on page 1 ; "If any data temperature 
exceeds limit and WS_SYS_OVERTMP is clear, set WS_SYS_OVERTEMP, ... log 
WS_SYS_TEMP_SHUT" p. 33); transmitting failure information related to the failure 
condition to an independently functional system recorder (system recorder shown in Figure 1; 
"[t]he processors are Microchip PC processors. . . . Each processor can either be a master or a 
slave and can control resources on itself or any other processor on the bus", p. 1), storing the 
failure information related to the failure condition in a system log (NVRAM shown in Figure 1 
and connected to system recorder), and reporting an occurrence of the failure condition ("If any 
data temperature exceeds limit and WS_SYS_OVERTMP is clear, set WS_SYS_OVERTEMP, 
send a TEMPERATURE event to the system and remote interfaces, log 
WS_SYS_TEMP_SHUT", p. 33). 

d. We had conceived of a control diagnostic and monitor subsystem for a server 
system. A document, entitled "Raptor System: A Bird's Eye View, Version 0.99", was written at 
least as early as November 2, 1995, as evidenced by the document date. A copy of the cover 
page, and pages 8 and 9 of document is attached as Exhibit B. Page 8, describes a system to 
monitor and manage specific functions of the first computer through a Control Diagnostic and 
Monitor (CDM) subsystem implemented by distributed CDM microprocessors connected to an 
I 2 C serial (CDM) bus. The CDM can supervise and manage selected environmental conditions 
externally from a remote second computer via the CDM bus and communication lines. 
Examples of monitored and managed environmental conditions of a computer are fan speed, the 
temperatures of the motherboard, and of the backplane. As is described on pages 8 and 9, the 
CDM subsystem supervises the log of all system events. 



-2- 



Appl. No. : 08/942,384 

Filed : October 1, 1997 

5. I, Karl S. Johnson, am listed as an inventor on provisional Patent Application Nos. 
60/046,397, 60/047,016, 60/046,416, each filed May 13, 1997, which each are priority applications 
for the subject application. 

6. We are the listed inventors on the subject regular patent applications filed on October 1, 
1997. 

7. All acts leading to the reduction of practice were performed in the United States. 

8. This declaration is submitted prior to a final rejection. 

Penalty of Perjury Statement 
We declare that all statements made herein of our own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful, false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful, false statements may jeopardize the validity of the application or any 
patent resulting therefrom. 
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Raptor Wire Service Architecture 



Introduction 



"Wire Service" is the code name for the Raptor project system control, diagnostic and maintenance 
bus ( formerly known as the CDM bus). Raptor is a completely "fly by wire" system - no switch, 
indicator or other control is directly connected to the function it monitors or controls, instead all the 
control and monitoring connections are made by the network of processors that comprise the "Wire 
Service" for the system. The processors are Microchip PIC processors and the network is a 400 kbps 
I^C serial bus. A limited understanding of I^C protocol is a prerequisite for understanding Wire 
Service protocols (See *The I^C-bus and how to use it" - Philips Semiconductor, Jan 1992). Control 
on this bus is distributed, each processor can be either a master or a slave and can control resources on 
itself or any other processor on the bus. 
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Introduction 

"Wire Service" is the code name for the Raptor project system control, diagnostic and maintenance 
bus ( formerly known as the CDM bus). Raptor is a completely "fly by wire" system - no switch, 
indicator or other control is directly connected to the function it monitors or controls, instead all the 
control and monitoring connections are made by the network of processors that comprise the "Wire 
Service" for the system. The processors are Microchip PIC processors and the network is a 400 kbps 
I 2 C serial bus. A limited understanding of PC protocol is a prerequisite for understanding Wire 
Service protocols (See "The I 2 C-bus and how to use it" - Philips Semiconductor, Jan 1992). Control 
on this bus is distributed, each processor can be either a master or a slave and can control resources on 
itself or any other processor on the bus. 



Wire Service Hardware Block Diagram 
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Logical Model 



All of the command, diagnostic, monitoring and history functions are accessed using a global network 
memory model. That is, any function may be queried simply by generating a network "read" request 
targeted at the function's known global network address. In the same fashion, a function may be 
exercised simply by "writing" to its global network address. Any Wire Service processor may initiate 
read/write activity by sending a message on the I 2 C bus to the processor responsible for the function ( 
which can be determined from the known global address of the function ). The network memory 
model includes typing information as part of the memory addressing information. It implements 
separate address spaces for each data type. This allows for compact internal storage and creates 
unique, more complex, data types which better suited to specific functions. 



Using a network global memory model places relatively modest requirements for the I 2 C message 
protocol. 

► All messages conform to the I 2 C message format including addressing and read/write indication. 

► All I 2 C messages use 7 bit addressing and the "General Call" address is not used. 

► Any processor can originate (be a Master) or respond (be a Slave) 

► All message transactions consist of I 2 C "Combined format" messages. This is made up of two 
back to back I 2 C simple messages with a repeated START condition between (which does not 
allow for re-arbitrating the bus). The first message is always a Write ( Master to Slave ) and the 
second message is a Read ( Slave to Master). 

► , Only two types of transactions are used: Memory-Read and Memory- Write. 

► Sub-Addressing formats vary depending on data type being used. 



Message Protocol 
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Generic Wire Service l 2 C Message Format 

The generic Wire Service message format is designed for easy encode/decode and reliability. It is not 
necessarily always the most compact representation possible 



Master Asserts START 
Offset MSB 


LSB 




ByteO 


Slave Address 


0 


0 means I^C write to slave 


Byte 1 


Data Type 


RAV 


RAV = 0 Mem Write / 1 Mem Read 


Byte 2 


Sub-Address 


Least Significant Byte of Address 


Byte 3 


Sub-Address ( Continued ) 


Most Significant Byte of Address 


Byte 4 


Length of Data (L) 


Write length or read max (Note 1) 


Byte 5 


Data Byte 1 


Present only for memory write 






: 


ByteN 


Data Byte L 




Byte N+l 


Check Byte 


For data integrity (Note 2) 


Master repeats START 






ByteO 


Slave Address (same) 


1 


1 means I^C read from slave 


Byte 1 


Length of Data (L) 


Length of data (if any) 


Byte 2 


Data Byte 1 










ByteN 


Data Byte L 




Byte N+l 


Status 


Status 0=Success otherwise Failure 


Byte N+2 


Check Byte 


For data integrity (Note 2) 



Note 1 : On a memory write, this is the length in bytes of the data immediately following ( not 
including status and check byte ). On a memory read, this specifies the maximum number of 
bytes of data that can be returned ( not including status and check byte ). 

Note 2: The check byte is only appended on actual I^C messages on the Wire Service Bus. It 
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guarantees integrity of a message on the wire. It is not required when sending messages through 
the system bus interface because it is automatically appended or checked by the interface. 
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Data Type Descriptions 

Each data type description includes a rational for its existence and an example simple protocol 
message. The check byte is not shown in the following message descriptions for clarity. Only the 
message description common to all views of Wire Service is shown, although the check byte will be 
appended and checked by all messages as they are physically sent on the Wire Service Bus. 

Bit Type 

The bit data type is to be used for simple logic valued items (TRUE/FALSE, ON/OFF, etc.) 
Read Bit Message 



Request 



Slave 
Address 


Type/RW 


Bit Addr 
LSB 


Bit Addr 
MSB 


Request 
1 




Response 










Slave 
Address 


Length 
1 


Bit Value 
(0/1) 


Status 
0/Success 




Write Bit Message 
Request 








Slave 
Address 


Type/RW 


Bit Addr 
LSB 


Bit Addr 
MSB 


Length 
1 


Bit Value 
(0/1) 


Response 










Slave 
Address 


Length 
0 


Status 
0/Success 







Byte Type 

The byte data type is to be used for single byte valued items (0-255) 

Read Byte Message 
Request 



Slave 


Type/RW 


Byte Addr 


Byte Addr 


Request 


Address 




LSB 


MSB 


1 



Response 

> i < I I 
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Slave 
Address 


Length 
1 


Byte 
Value 


Status 
O/Success 




Write Byte 
Request 


Message 








Slave 
Address 


Type/RW 


Byte Addr 
LSB 


Byte Addr 
MSB 


Length 
1 


Byte Value 
(0-255) 


Response 












Slave 
Address 


Length 
0 


Status 
O/Success 







. String Type 

The String type is designed to handle data that is best organized as variable length strings of 0 to 255 
bytes. Internal allocation of string storage for each string may be less than 255 bytes, and writing a 
string longer than available storage will return an error. 

Read String Message 



Request 



Slave 
Address 


Type,RW 


String Addr 
LSB 


String 
Addr MSB 


Request 
0-255 






Response 






Slave 
Address 


Length 
N 


String 
Data 1 




String 
Data N 


Status 
O/Success 




Write String Message 
Request 




Slave 
Address 


TypeR 
W 


String 
Addr LSB 


String 
Addr MSB 


Length ■ 
N 


String 
Data 1 




String 
DataN 


Response 






Slave 
Address 


Length 
(f 


Status 
O/Success 
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Lock Byte Type 

The lock byte data type is to be used for single bytes of data used to control synchronization as it 
performs a test and set operation on the byte. The byte is unconditionally set to zero and the original 
value of the byte is returned. This data type shares the same address space with the Byte Array data 
type. 



Lock Byte Message (Read Type) 
Request 



Slave 
Address 


Type/RW 


Byte Addr 
LSB 


Byte Addr 
MSB 


Request 
1 


Response 










Slave 
Address 


Length 
1 


Original 
Byte Value 


Status 
O/Succes 
s 





Byte Array Type 

The byte array data type is to be used for general storage of data that is unanticipated in this 
architecture. This storage is only implemented in the Wire Service processor with NVRAM. External 
code will be responsible for managing allocation/deallocation and data directory information. ' 
Recommend that byte at address 0 be the lock byte for modification of the data directory.' * 

Read Byte Array Message 
Request 



Slave 
Address 


Type/RW 


Start Addr 
LSB 


Start Addr 
MSB 


Request 
1-255 




Response 






Slave 
Address 


Length 
N 


Array 
Data 1 




Array 
DataN 


Status 
O/Success 




Write Byte Array Message 
Request 




' Slave 
Address 


Type/RW 


Start Addr 
LSB 


Start Addr 
MSB 


Length 
N 


Array 
Data 1 




Array 
DataN 


Response 




Slave 


Length 


Status 
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Address 



O/Success 



Log Type 

The Log data type is to be used for logging byte strings in circular log buffer. It is used to record 
system events in the NVRAM system log. 

Read Log Message 
Request 



Slave 
Address 


Type/RW 


Log Addr 
LSB 


Log Addr 
MSB 


Request 
1-255 




Response 












Slave 
Address 


Length 
N+6 


Log Time 
LSB 


Log Time 


Log Time 


Log Time 
MSB 


Log Addr 
LSB 


Log Addr 
MSB 


Log Data 
Byte 1 




Log Data 
ByteN 


Status 
O/Success 






Write Log Message 
Request 










Type/RW 


N/A 


N/A 


Length 
N 


Log Data 
Byte 1 




Log Data 
ByteN 





Response 



Slave 


Length 


Status 


Address 


0 


O/Success 



The addressing of log entries has some special characteristics: 

• Reading address 65565 (Oxffff) is special - It represents the address of the latest entry in the log. 

• Reading address 65564 (Oxfffe) is also special - It represents the address of the earliest available 
entry. 

• The address of real log entries wraps at 65519 (Oxffef). The next sequential entry after 65519 is 0. 

• The address of is ignored on write and the next available entry is written. 

• To read the entire log in forward time order, read entry at address 65564. This returns the first log 
entry along with its actual log address. Increment that address by one and read that entry. Repeat 
the last step until status indicates failure. 

• To read the entire log in reverse time order, read entry at address 65565. This returns the last log 
entry along with its actual log address. Decrement that address by one and read that entry. Repeat 
the last step until status indicates failure. 

• To keep a complete external copy of the log, first read the entire log in forward time order and 
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remember the last valid entry. Then periodically read forward from the remembered last valid 
entry to the end and add that to the external copy. 

There are also conventions for the Log Data portion of the message or response. These are 
conventions and are not enforced by the Wire Service logging function. The conventions are as 
follows: 

Log Data Byte 1 : Severity Level Byte 
0x00 - Unknown 
0x10 - Informational 
0x20 - Warning 
0x30 - Error 

0x40 - Severe/Fatal Error 

Log Data Byte 2: Source/Encoding Byte - which entity logged the entry in the 4 high bits 
0x00 - Wire Service Internal 
0x10 - Onboard Diagnostics 
0x20 - External Diagnostics 
0x30 - BIOS 

0x40 - Time Synchronizer 

0x50 - Windows 

0x60 - Windows/NT 

0x70 -NetWare 

0x80 - OS/2 

0x90 - UNIX 

OxAO - VAX/VMS 

- which type of encoding of the message is used in the 4 low bits of the byte. 
0x00 - Binary 
0x01 - ASCII 
0x02 - Unicode 

Thus an external diagnostics ASCII error message would have a severity and source/encoding byte 
values of 0x30 and 0x21 . 

For binary encoded messages, additional conventions apply: 

Log Data Byte 3 and 4 are used as the LSB and MSB of a 16 bit Message Identifier. Each source 
group (OS's, BIOS, etc..) that wishes to log binary messages must maintain a file in a common format 
containing the definition of ALL possible binary messages from their source. This file contains the 
Identifier value and formatting string and any descriptive comments for each message. Identmust be 
maintained by each possible message source group and supplied as a file to any requestor. (Obsolete 
Message Identifiers MAY NOT be reused for old version compatability reasons) Log Data Bytes 5 
and beyond are message arguments in format list order. 
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An example binary message definition file entry for the BIOS might be: 

00045 "DIMM configuration bad - row %db - Types %3.3db %3.3db %3.3db %3.3db" 

Note: Most U C" printf formatting items will work except that the final letter of a numeric 
formatting sequence must be b (byte) s (short) or 1 (long) to how many bytes of the log message 
data it takes. Strings take up to the first null (zero terminated). 



Event Type 

The event data type is to be used for alerting external interfaces of events in the Wire Service 
network. Event memory is organized as a bit vector. Each bit in the vector represents a particular type 
of event and there are a minimum of 32 bits in the vector.. Writing an event sets the bit representing 
the event in the bit vector. Whenever any bit in the event bit vector is non-zero, the interface indicates 
that events are present.. 

Reading the event type returns the complete event bit vector as a byte string of four (4) bytes with bit 
0 being the low order bit of the first byte of the byte string. Once a read events completes 
successfully, the bit vector is cleared of event indications automatically. 



Read Events Message 
Request 



Slave 
Address 


Type/RW 


N/A 


N/A 


Request 
-1-255 




Response 


Slave 
Address 


Length 
N(4) 


Events 
1-8 




Events 
25-32 


Status 
0/Success 


Write Event Message 
Request 


Slave 
Address 


Type/RW 


N/A 


N/A 


Length 
1 


Event 
IDO-32) 


Response 




Slave 
Address 


Length 
0 


Status 
0/Success 



Possible Event Types: 
CPU Status Change 
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Power Status Change 
Canister Status Change 
Fan Status Change 
Communications Queue Event 

Screen Type 

The screen data type is to be used for communication of character mode screen information from the 
system BIOS to remote management interface. 



Read Screen Message 
Request 



Slave 


Type/RW 


S Addr 


S Addr 


Request 




Address 




LSB 


MSB 


1-255 




Response 












Slave 


Length 


Screen 




Screen 


Status 


Address 


N 


Data 1 




DataN 


O/Success 



Write Screen Message 
Request 



Slave 


Type/RW 


S Addr 


S Addr 


Length 


Screen 




Screen 


Address 




LSB 


MSB 


N 


Data 1 




DataN 



Response 



Slave 


Length 


Status 


Address 


0 


O/Success 



The screen address space consists of an image of character video memory for a 80x50 screen. Each 
character cell has both a character byte and attribute byte for a total of 8000 bytes of screen memory. 
Additionally memory is implemented up to address 8191. Use of the bytes above 8000 are defined by 
the BIOS and the remote managment software. Addresses 8001 and 8002 are suggested as the cursor 
address register. 
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Queue Type 

The Queue type is designed to move data between the system and a remote management software. 
Queues are written/read in FIFO order and no access is available to any elements except to read the 
first and write the last. Queue elements are variable length up to 255 bytes. If there is no room to add 
an element to a queue, the entry is not added and failure status is returned. If there is no queue 
element available to read, failure status is returned. Interpretation of data in the queue elements is left 
to external software. 

Note: The Queue ID in the normal address field refers to which Queue of several possible queues and 
NOT the queue element address. 



Read Queue Message 
Request 



Slave 
Address 


Type/RW 


Queue ID 
LSB 


Queue ED 
MSB 


Request 
0-255 




Response 












Slave 
Address 


Length 
N 


Queue 
Data 1 




Queue 
DataN 


Status 
0/Success 




Write Queue Message 
Request 










Type/RW 


N/A 


N/A 


Length 
N 


Queue 
DataO 




Queue 
DataN 



Response 



Slave 


Length 


Status 


Address 


0 


0/Success 
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System Bus Interface 



Introduction 



The System Bus Interface to Wire Service is the interface used by any of the system processors to 
read or write Wire Service memory by sending Wire Service messages and receive responses. The 
Wire Service messages and responses are exactly as described in the previous section ( Note: The 
system processor is not required to compute and add or process check bytes on the message as the 
interface processor does that function). It is assumed that interface is reliable between the system 
processors and the interface processor.. 

The System Bus interface to the Wire Service I^C bus is implemented by a dedicated Wire Service 
System Interface Processor (WSSIP)and 2 message FIFOs, one for message data written by the 
system processors to the System Bus Interface (requests) and one for message data returned by the 
system bus interface (responses). The system bus interface appears in system I/O space as 2 registers, 
each 8 bits wide. The lower register is the message data register (MDR) and the upper register is the 
command and status register (CSR). 

The MDR, when written from the system bus, loads a byte into the request FIFO and when read from 
the system bus presents a byte unloaded from the response FIFO if any. The FIFOs may be most 
quickly loaded and unloaded via REP OUT or REP IN instructions executed on the system 
processor(s). The protocol is designed to load and unload these FIFOs with a minimum of 
interpretation of the message data (i.e. all message fragments have length fields in the same position 
and same interpretation). These FIFOs serve two functions: 1) They match speeds between the very 
fast System Bus and the slower WSSIP and I^C bus and 2) They temporarily serve as interim 
memory for the messages relieving the Wire Service processor of that requirement. 

The CSR is implemented with a direct interface to the WSSIP. Writing to this register from the 
system bus interrupts the WSSIP and may cause it to take actions depending on the value written. One 
action could be to change the value returned if there is a read from the system bus to this register. 
Note that there is no hardwired relation between values written to and read from this register and also 
that there is a processing interval between writing from the system bus to this register and the WSSIP 
reading the register value written. This could lead to data loss should the system bus write a second 
time to the CSR before the WSSIP read the first item. To avoid this problem, all writes to the CSR 
eventually result in some change to the value read from the CSR. Thus after writing the CSR, you 
should wait to see the change in the CSR indicating it has processed the data written to it. 



Interface Operation 



Operation of the system bus interface is controlled through the CSR. 



CSR Write Format 



NetFRAME CONFIDENTIAL DOCUMENT 



Page 13 



Raptor Wire Service Architecture 



Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 



Int Req 



Command Value 



Field Descriptions 

Command Value - The value corresponding to the command to execute. 

Int Req - Commands are modified by this bit to request an interrupt upon completion. 



CSR Read Format 



Bit 7 


Bit 6 


Bit 5 


Bit 4 


Bit 3 


Bit 2 Bit 1 Bit 0 


Int Pend 


Int Ena 


Events 


Done 




Allocated To 



Field Descriptions 



Allocated - The interface is currently in use. Only Allocate commands will be accepted until 
set. 

Done - A command has completed ( except for Allocate, Deallocate and Clear Done ). 

Events - The Event Queue on the WSSIP is not empty if this bit is set. 

Int Ena - Interrupt on Events bit going from 0 to 1 is enabled. 

Int Pending - An interrupt source is active. 



CSR commands that are currently defined and their actions: 



Commands 


Value 


Actions 


Allocate 


1-7 
0x01-07 


Clears both FIFOs of any stale data, clears Done and then sets Allocated 
To Identifer field to lower 3 bits of allocate command value. Only 
executed if Allocated To field is zero. Generally, first command of 
sequence. 


Deallocate 


16 
0x10 


Clears Done and Allocated, Generally the last command of transaction 
sequence. 


Enable Ints 


17 
0x11 


Enables interrupts on Events bit being set. Sets Done. May cause 
interrupt if Events is already set. 


Disable Ints 


18 
0x12 


Disables interrupts on Events bit being set. Sets Done. 


Message 


19 
0x13 


Request in request FIFO is sent on the l2c bus and the response is 
received into response FIFO. Sets Done. I^C bus errors create unique 
error response. 


Clear Done 


20 


Clears the Done bit. 
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0x14 




Reset 


165 
0xa5 


Unconditionally clears all bits in the Read CSR except "Events", 
Aborts any currently in progress message operation and clears any 
interrupt. 



Note: The purpose of the Allocate command and Allocated To field in the CSR is to provide for some 
degree of coordination in the case where multiple threads (or processors ) are each trying to use the 
interface. The proper use of the Allocate command is to assign a different allocation identifer ( 
presented in the lower three (3) bits of the Allocate command ) to each possible conflicting allocation 
thread of control. Allocate commands will only succeed if the Allocated To field of the CSR is zero: 
If more than one thread issues an Allocate command at near the same time, only one will be 
recognized and the low order three bits of that command will be placed in the Allocated To field 
indicating the which thread has allocated the interface sucessfully. The losing thread realizes that the 
Allocated To field is not zero and not its ID, so it must give-up and try to allocate the interface later. 

The following is a state diagram that details the expected use of the Wire Service system interface. 

Not every possible error condition and possible state transition is anticipated by the above diagram, 
but it does indicate the intended operational sequence to be used with the interface in non-interrupt 
driven mode. To extend the diagram to interrupt mode, simply add the interrupt request bit to each 
command desired and instead of waiting for the appropriate bit, exit and wait for the interrupt. In most 
cases, the only command in which it makes sense to request an interrupt is the Message command. All 
other commands either complete very quickly or ignore the interrupt bit (Reset Command). 
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Note: The Reset Command is a problem determining if it is complete as it sets no bit and may take 
some time to work because of existing activity, so it seems the only way to do it now it to set it and 
wait. 



Wait for 
Allocated To 
Clear 

0 



Normal 

Entry/Exit 
/ \ Deallocating 

^ ^ Interface 



Wait for 
lot Ena Bit 
to Set/Clear 

0 



Change Event 
Interrupts 



Initialized 
Interface 



Wait for 
Done Bit 




Reset 
Interface 



Read Response 
From FIFO 



Clearing 
Done Status 



Message 
Complete 
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Wire Service Network Physical Connections 

The following table describe all of the physical signal connections to all of the Wire Service 
processors. The names for the connections will be related to network accessible memory data in the 
section which follows called "Wire Service Network Memory Map". 

Note: All signal types and definitions are from the viewpoint of the individual Wire Service PIC 
processor 

( e.g. Input means input to PIC processor ) 

Wire Service System Bus Interface (System Type ID: SO) Processor ID 10 



Pin 


Type 


Name Function Notes 


RAO 


I 


SO FIFO IEF2 


In FIFO (ISA Writes) Empty Flag (Active Low) 


Status Flags for both ISA bus 
FIFO's. 

Need to monitor for incoming 
message overruns. Also must 
assure that output FIFO is empty 
before loading output message. 


RA1 


| 


S0_FIFO_IHFZ 


In FIFO (ISA Writes) Half-full Flag (Active Low) 


RA2 


I 


SO FIFO IFFZ 


In FIFO (ISA Writes) Full Flag (Active Low) 


RA3 


I 


S0_FIFO_OEFZ 


Out FIFO (ISA Reads) Empty Flag (Active Low) 


RA4 


I 


SO FIFO OHFZ 


Out FIFO (ISA Reads) Half-full Flag (Active Low) 


RA5 


1 


SO FIFO OFF2 


Out FIFO (ISA Reads) Full Flag (Active Low) 


RBO 


I/O 


SO FIFO DO 


ISA FIFOs Data bus Bit 0 


This is an 8 bit bi-directional port 
for the ISA FIFO data bus. These 
bits should drive the bus before 
asserting FIFO Write and can be 
read after tri-stating and . - 
asserting FIFO Read 


RB1 


I/O 


SO FIFO D1 


ISA FIFOs Data bus Bit 1 


RB2 


I/O 


SO FIFO D2 


ISA FIFOs Data bus Bit 2 


RB3 


I/O 


SO FIFO D3 


ISA FIFOs Data bus Bit 3 


RB4 


I/O 


S0_FIFO_D4 


ISA FIFOs Data bus Bit 4 


RB5 


I/O 


SO FIFO D5 


ISA FIFOs Data bus Bit 5 


RB6 


I/O 


SO FIFO D6 


ISA FIFOs Data bus Bit 6 


RB7 


I/O 


SO FIFO D7 


ISA FIFOs Data bus Bit 7 


RCO 


0 


SO FIFO RZ 


FIFO (ISA Writes) Read (Assert Low) 


Assert to read the In FIFO 


RC1 


0 


SO FIFO WZ 


PIC to ISA FIFO (ISA Reads) Write (Assert Low) 


Assert to write the Out FIFO 


RC2 


0 


SO ISA INT 


PIC to ISA Interrupt Request (Assert ? ) 


Level Interrupt to ISA bus 


RC3 


I/O 


SO I2C DATA 


Wire Service Bus Clock (I2C) 


Only used for I2C 


RC4 


I/O 


SO I2C CLK 


Wire Service Bus Data (I2C) 


RC5 


o 


SO FIFO RST2 


In and Out FIFOs Reset (Assert Low) 


Resets both FIFOs 


RC6 


o 


SO FIFO IRTZ 


In FIFO (ISA Writes) Retransmit (Assert Low) 


Resets the Read pointer to 0 


RC7 


0 


SO FIFO ORTZ 


Out FIFO (ISA Reads) Retransmit (Assert Low) 


Resets the Read pointer to 0 


RDO 


I/O 


SO CSR DO 


ISA External Data bus Bit 0 ( Slave parallel port ) 


The slave parallel port is used as 
a bidirectional control and status 
register on the ISA bus. 


RD1 


I/O 


SO CSR D1 


ISA External Data bus Bit 1 ( Slave parallel port ) 


RD2 


I/O 


SO CSR D2 


ISA External Data bus Bit 2 ( Slave parallel port ) 


RD3 


I/O 


SO CSR D3 


ISA External Data bus Bit 3 ( Slave parallel port ) 


RD4 


I/O 


SO CSR D4 


ISA External Data bus Bit 4 ( Slave parallel port ) 


RD5 


I/O 


SO CSR D5 


ISA External Data bus Bit 5 ( Slave parallel port ) 


RD6 


I/O 


SO CSR D6 


ISA External Data bus Bit 6 ( Slave parallel port ) 


RD7 


I/O 


SO CSR D7 


ISA External Data bus Bit 7 ( Slave parallel port ) 


REO 


1 


SO CSR RZ 


ISA Read Slave Parallel Port (Assert Low) 


Not directly manipulated after 
setting port D/E to act as slave 
parallel port 
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S0_CSR_WZ 
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RE2 



SO CSR SZ 



ISA Slave Parallel Port Select (Assert Low) 
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Wire Service System Monitor A (System Type 10 S1) Processor ID 3 
Pin Type Name Function Notes 



RAO 


O 


S1 FAN HI 


System Board fan speed to high (Assert Hi) 


Assert on any SB fan failure 


RA1 


O 


S1 SB FAN LEO 


System Board fan fault LED 


Assert on any SB fan failure 


RA2 


o 


S1_BC_DS0 


Bus/Core Speed Ratio and DIMM Select Mux Bit 0 


During system reset these bits 
select bus/core speed ratio for alt 
Drocessors Otherwise thev 
select which DIMM presents its 
type on DIMM type port. 


RA3 


o 


S1 BC DS1 


Bus/Core Speed Ratio and DIMM Select Mux Bit 1 


RA4 


o 


S1 BC DS2 


Bus/Core Speed Ratio and DIMM Select Mux Bit 2 


RA5 


o 


S1 BC DS3 


Bus/Core Speed Ratio and DIMM Select Mux Bit 3 


RBO 


I/O 


S1 LCD DO 


LCD Controller Data Bus bit 0 


These lines make up the 8 bit 
data bus to the LCD display 


RB1 


I/O 


S1 LCD D1 


LCD Controller Data Bus bit 1 


RB2 


I/O 


S1 LCD D2 


LCD Controller Data Bus bit 2 


RB3 


I/O 


S1_LCD_D3 


LCD Controller Data Bus bit 3 


RB4 


I/O 


S1 LCD 04 


LCD Controller Data Bus bit 4 


RB5 


I/O 


S1_LCD_D5 


LCD Controller Data Bus bit 5 


RB6 


I/O 


S1 LCD D6 


LCD Controller Data Bus bit 6 


RB7 


I/O 


S1 LCD D7 


LCD Controller Data Bus bit 7 


RCO 


1 


S1 FAN TP 


Tachometer pulse input from selected fan 


Generally routed to counter 


RC1 


O? 


S1 OK TO RUN 


Drives SYS_PWRGOOD signal 


System starts on 0->1 transition 


RC2 


1 


S1 RESET SW 


Undebounced input from System Reset switch 




RC3 


I/O 


S1 I2C DATA 


Wire Service Bus Clock (I2C) 


Only used for I2C 


RC4 


I/O 


S1 I2C CLK 


Wire Service Bus Data (I2C) 


RC5 


0 


S1 FAN SELO 


Fan Tachometer Multiplexer Select Bit 0 


Used to select which fan 
tachometer pulse output is gated 


RC6 


o 


S1 FAN SEL1 


Fan Tachometer Multiplexer Select Bit 1 


RC7 


o 


S1 FAN SEL2 


Fan Tachometer Multiplexer Select Bit 2 


to 91 FAN TP * 


RDO 




S1 DIMM DO 


DIMM Type port bit 0 


These lines make up an 8 bit port 
which on which the DIMM 
module in the slot selected by 
S1 BC DS0..3 presents its type 
data if any. If no DIMM is present 
in the slot selected the DIMM 
type bits are all Vs. 


RD1 




S1 DIMM D1 


DIMM Type port bit 1 


RD2 




S1 DIMM D2 


DIMM Type port bit 2 


RD3 




S1 DIMM D3 


DIMM Type port bit 3 


RD4 




S1 DIMM D4 


DIMM Type port bit 4 


RD5 




S1 DIMM D5 


DIMM Type port bits 


RD6 




S1 DIMM D6 


DIMM Type port bit 6 


RD7 




S1 DIMM D7 


DIMM Type port bit 7 


REO 


o 


S1 LCD RS 


LCD Controller Register Select 


See LCD Controller data sheet 


RE1 


o 


S1 LCD EN A 


LCD Controller Register Enable 


for details of operation of these 


RE2 


o 


S1 LCD RW 


LCD Controller Register Read/Write 


signals 
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Wire Service System Monitor B (System Type ID S2) Processor ID 4 



Pin 


Type 


Name 


Function 


Notes 


RAO 


0 


S2 FLASH LED 


Display the Enable/Disable state of BIOS Flash ROM 


Should track S2 FLASH ENA 


RA1 


0 


S2 SBFLT LEDO 


System Board FRU LED Pin 0 (bicoior LED) 


Drive in different combinations for 


RA2 


0 


S2 SBFLT LED1 


System Board FRU LED Pin 1 (bicoior LED) 


Orr, AMBER, bKccN 


RA3 


o 


S2 OVRTMP LED 


Over Temperature LED 




RA4 


I 


S2 TEMP CPU4 


Thermal Fault - CPU 4 


Indicator that CPU has exceeded 


RA5 


I 


S2 TEMP CPU3 


Thermal Fault - CPU 3 


temperature limit and faulted 


RBO 


o 


S2_SB^JTAG 


Enable System Board JTAG Chain TMS (Not Yet 
Implemented) 






r\ 
\J 


CO Ct ACU \A/C 

oZ rLAon Wt 


oystem tsiuo rLAon write enable 




PRO 


1 
1 


CO C| ACU Q\ a/ 
rLAon oW 


oystem biuo rLAon wnte tnaoie owitcn 




r\oo 


1 


CO kIMI C\A/ 

oZ NMl oW 


oystem Non-MasKabie interrupt (NMl) owitcn 






1 
1 


oz KUlx UrUl 


Power Good signal from CPU 1 


Indicator that power regulator for 


DDE 


1 
1 


CO DOI/ /~*D1 io 

oZ rU»\ UrU^ 


Power Good signal from CPU 2 


CPU is operating correctly. Only 
valid if corresponding CPU is 
present (S2 PRES CPUx) 


one 


1 


CO D/™\1/' rf^OI IO 

oZ rUrs. t/PUo 


Power Good signal from CPU 3 


DDT 


1 

1 


oz rvJK. OrU4 


Power Good signal from CPU 4 




X 




unused 




KOl 


X 




unused 




ROz 


O 


CO klAJH ODI lit 

oz NMl UPU4 


NMl Request for CPU 4 


T _ _ _ 1 _ X . . ft. 1 ft J 1 L y™* r"» 1 t 

Toggle to cause NMl to CPU 






CO lOf* /"M 

oZ IZO OLK. 


Wire Service Bus Pata (I2C) 


Only used for I2C 




\ir\ 


CO IO/"* /"M t/" 

oZ IZO ULK 


Wire Service Bus Data (I2C) 




RL*0 


U 


oz NMl GPU3 


Mill — . — - . .~ _ » r _ _ /~\»-\» 1 a 

NMl Request for CPU 3 


See S2_NMLCPU4 above 




u 


CO MhAt /™»OI IO 

oz_NMI_UPUz 


nmi Request tor CPU z 




KO/ 


u 


oz NMl OrUI 


ft 1 ft J 1 n . A A k X A. -~ I'M I 4 

nmi Request tor CPU 1 




KUU 





CO DD d O /"*Ot M 

oz PRbo UPU1 


Presence detection bit - CPU 1 


Asserted when a processor 


pni 

r\U I 




CO DDCC f*D| IO 
OZ rKto Orllt 


Presence detection bit - CPU 2 


inserted in the system board 


RD2 




S2 PRES CPU3 


Presence detection bit - CPU 3 




RD3 




S2 PRES CPU4 


Presence detection bit - CPU 4 




RD4 




S2 ERROR CPU1 


Processor Fault bit - CPU 1 


Processor either failed BIST on 


RD5 




S2 ERROR CPU2 


Processor Fault bit - CPU 2 


startup or later other fault. Only 
valid if corresponding CPU is 
present (S2 PRES CPUx) 


RD6 




S2 ERROR CPU3 


Processor Fault bit - CPU 3 


RD7 




S2 ERROR CPU4 


Processor Fault bit - CPU 4 


REO 


0 


S2 SYSFLT LED 


System Fault summary LED 




RE1 




S2JTEMP_CPU2 


Thermal Fault -CPU 2 


See S2_TEMP_CPU4 above 


RE2 




S2 TEMP CPU1 


Thermal Fault - CPU 1 
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Wire Service System Recorder (System Type ID S3 ) Processor ID 1 



Pin 


Type 


Name 


Function 


Notes 


RAO 


0 


S3 NVRAM A8 


NVRAM Address Bit 8 


NVRAM Address Bus Bits 8-13 


RA1 


0 


S3 NVRAM A9 


NVRAM Address Bit 9 


RA2 


0 


S3 NVRAM A10 


NVRAM Address Bit 10 




RA3 


O 


S3 NVRAM A11 


NVRAM Address Bit 11 




RA4 


o 


S3 NVRAM A12 


NVRAM Address Bit 12 




RA5 


0 


S3 NVRAM A13 


NVRAM Address Bit 13 




RBO 


I/O 


S3 NVRAM DO 


NVRAM Data Bit 0 


NVRAM 8 Bit Data Bus 


RB1 


I/O 


S3 NVRAM D1 


NVRAM Data Bit 1 




RB2 


I/O 


S3 NVRAM D2 


NVRAM Data Bit 2 




RB3 


I/O 


S3 NVRAM D3 


NVRAM Data Bit 3 




RB4 


I/O 


S3 NVRAM D4 


NVRAM Data Bit 4 




RB5 


I/O 


S3 NVRAM D5 


NVRAM Data Bit 5 




RB6 


I/O 


S3 NVRAM D6 


NVRAM Data Bit 6 




RB7 


I/O 


S3 NVRAM D7 


NVRAM Data Bit 7 




RCO 


O 


S3 NVRAM CSZ 


NVRAM Chip Select (Negative Logic) 


Control signals for NVRAM - See 


RC1 


O 


S3 NVRAM OEZ 


NVRAM Output Enable (Negative Logic) 


Dallas DS1245 data sheet 


RC2 


o 


S3 NVRAM WEZ 


NVRAM Write Enable (Negative Logic) 




RC3 


I/O 


S3 I2C CLK 


Wire Service Bus Data (I2C) 


Only used for I2C 


RC4 


I/O 


S3 I2C CLK 


Wire Service Bus Data (I2C) 


RC5 


o 


S3 NVRAM A14 


NVRAM Address Bit 14 


NVRAM Address Bus Bits 14-16 


RC6 


o 


S3 NVRAM A15 


NVRAM Address Bit 15 




RC7 


o 


S3 NVRAM A16 


NVRAM Address Bit 16 




RDO 


o 


S3 NVRAM AO 


NVRAM Address Bit 0 


NVRAM Address Bus Bits 0-7 


RD1 


0 


S3 NVRAM A1 


NVfcAM Address Bit 1 




RD2 


0 


S3 NVRAM A2 


NVRAM Address Bit 2 




RD3 


o 


S3 NVRAM A3 


NVRAM Address Bit 3 




RD4 


o 


S3 NVRAM A4 


NVRAM Address Bit 4 




RD5 


o 


S3 NVRAM A5 


NVRAM Address Bit 5 




RD6 


o 


S3 NVRAM A6 


NVRAM Address Bit 6 




RD7 


o 


S3 NVRAM A7 


NVRAM Address Bit 7 




REO 


o 


S3 RTC CLK 


Real Time Clock - Data Clock 


See Dallas DS1603 data sheet 


RE1 


I 


S3 RTC DATA 


Real Time Clock - Serial Data 




RE2 


o 


S3 RTC RSTZ 


Real Time Clock - Protocol Reset (Negative Logic) 
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Wire Service Backplane (System Type ID S4) Processor ID 2 
Pin Type Name Function Notes 



RAO 


A 


S4 VOLTS P5V 


Analog measure of system +5 voU main supply 


Use D/A converter to read 
voltages as 0-255. Calibration 
constants are determined 
externally 


RA1 


A 


S4 VOLTS P3V 


Analog measure of system +3.3 volt main supply 


RA2 


A 


S4_VOLTS_P12V 


Analog measure of system +12 volt main supply 


RA3 


A 


S4 VREF 


Voltage Reference for A/D converter 


I Ini icpH 


RA4 


X 








RA5 


A 


S4_VOLTS N12V 


Analog measure of system -12 volt main supply 


SeeS4 VOLTS P5V 


RBO 


I/O 


S4_PSN_CAN1 


Presence and Serial Number I/O for Canister 1 


ThPCP o re* all lirtAC t/"* aha vA/i ro 

■ < IwC ul G all III ICC UJ LH IC Wll G 

serial data EPROMS. See Dallas 
DS250x data sheet for 
programming information 


RB1 


I/O 


S4 PSN CAN2 


Presence and Serial Number I/O for Canister 2 


RB2 


I/O 


S4 PSN CAN3 


Presence and Serial Number I/O for Canister 3 


RB3 


I/O 


S4 PSN CAN4 


Presence and Serial Number I/O for Canister 4 


RB4 


I/O 


S4 PSN CANS 


Presence and Serial Number I/O for Canister 5 


RB5 


I/O 


S4_PSN_CAN6 


Presence and Serial Number I/O for Canister 6 


RB6 


I/O 


S4 PSN CAN7 


Presence and Serial Number I/O for Canister 7 


RB7 


I/O 


S4_PSNCAN8 


Presence and Serial Number I/O for Canister ft 


RCO 


X 








RC1 


I 


S4_ACOK_PS3 


A/C Input OK to Power Supply 3 


Ctvu i\(4 r+it*rk r\r\\\/ rf DC M (r\r 

oiKjuiu cnecK oniy n roN Tor 
power supply indicates presence. 


RC2 


I 


S4_ACOK_PS2 


A/C Input OK to Power Supply 2 


RC3 


I/O 


S4 I2C CLK 


Wire Service Bus Data (I2C) 




RC4 


I/O 


S4 I2C CLK 


Wire Service Bus Data (I2C) 


RC5 


I 


S4_ACOK_PS1 


A/C Input OK to Power Supply 1 




RC6 


O 


S4 POWER ON 


Enable main outout from nowpr *?unnlip<; 




RC7 


I 


S4_POWER SW 


Power On/Off switch (undebounced* 




RDO 


I/O 


S4 PSN PS1 


Presence and Serial Number for Power Supply 1 


These are all lines to one wire 
serial data EPROMS. See Dallas 
DS250x data sheet 


RD1 


I/O 


S4 PSN PS2 


Presence and Serial Number for Power Supply 2 


RD2 


I/O 


S4 PSN PS3 


Presence and Serial Number fcr Power Supply 3 


RD3 


I/O 


S4 PSN BP 


Presence and Serial Number for Backplane 


Dallas DS250x also 


RD4 


I/O 


S4 PSN SB 


Presence and Serial Number for System Board 


Dallas DS250x also 


RD5 


I 


S4 BP TYPE 


Backplane Type ( 0: Small 1: Large) 




RD6 


I/O 


S4 TEMP SCL 


Temperature Bus Clock 


I2C local bus for temperature 
probes at different system points 


RD7 


I/O 


S4 TEMP SDA 


Temperature Bus Serial Data 


REO 


I 


S4 DCOK PS3 


D/C Output OK from Power Supply 3 


Should check only rf PSN for 
power supply indicates presence. 


RE1 


I 


S4 DCOK PS2 


D/C Output OK from Power Supply 2 


RE2 


I 


S4 DCOK PS1 


D/C Output OK from Power Supply 1 
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Wire Service Canister (System Type ID S5) Processor ID 2x where x is the slot ID 



Pin 


Type 


Name 


Function 


Notes 


RAO 


0 


S5 P12V ENA 


Turns on +/- 12 volt to all PCI slots 


Used to sequence power to PCI 


RA1 


0 


S5 P5V EISEA4 


Turns on +5 volts to PCI slot 4 


cards. 


RA2 


0 


S5 P5V ENA3 


Turns on +5 volts to PCI slot "\ 




RA3 


0 


S5 P5V ENA2 


Turns on +5 volte tn PCA slot 7 




RA4 


0 


S5 P5V ENA1 


Turns on +5 volts to PCI slot 1 




RA5 


0 


S5 PSLOT5 ENA 


Tunis on nower on slot S rarrl fif anv^ 

< mi mo vi i ^ufvvi \j\ i oiv/i sj vui u \il ally/ 


rMWdyo lUtll UTI Idol 


RBO 




S5 CAN AO 


Canister Address hit 0 


ueieimine in© wire oervice ous 


RB1 




S5 CAN A1 


Canister Address hit 1 


address of thus canister 


RB2 




S5 CAN A2 


Canister Address hit 0 




RB3 




S5 PRSNT S5 


Snerial ^Int HOP/PCI inmruaM nrnconf 


Indicates something is in slot 5 


RB4 


I/O 


S5 PSN S5 


Present Serial Mi imhor fr\r civiriol clni ^ 


rrom Uo zoux in slot o card (it 
IOP) 


RB5 


X 








RB6 


X 








RB7 


X 








RCO 


I 


S5 FAN TP 


Tachometer pulse input from selected fan 


Generally routed to counter 


RC1 


0 


S5 FAN SELO 


Fan Tachometer Multiplexer Select Bit 0 


Select which fan to monitor tach. 


RC2 


X 








RC3 


I/O 


S5 I2C CLK 


Wire Service Bus Data (I2C) 


Only used for I2C^ 


RC4 


I/O 


S5 I2C Cl-K 


,Wire Service Bus Data (I2C) 




RC5 


0 


S5 CAN FAN LED 


Canister fan fault LED 


Assert on any Canister fan failure 


RC6 


o 


S5 CANFLT LEDO 


Canister FRU LED Pin 0 (bicotor LED) 


Drive in different combinations for 


RC7 


o 


S5 CANFLT LED1 


Canister FRU LED Pin 1 (bicotor LED) 


OFF, AMBER, GREEN 


RDO 


I 


S5 PRSNT S1A 


PCI card present in Slot 1 (A pin) 


PCI slots have 2 presence pins - 


RD1 


I 


S5 PRSNT S1B 


PCI card present in Slot 1 (B pin) 


see PCI spec for usage and 


RD2 




S5 PRSNT S2A 


PCI card present in Slot 2 (A pin) 


meaning. 


RD3 




S5 PRSNT S2B 


PCI card present in Slot 2 (B pin) 




RD4 




S5 PRSNT S3A 


PCI card present in Slot 3 (A pin) 




RD5 




S5 PRSNT S3B 


PCI card present in Slot 3 (B pin) 




RD6 




S5 PRSNT S4A 


PCI card present in Slot 4 (A pin) 




RD7 




S5 PRSNT S4B 


PCI card present in Slot 4 (B pin) 




REO 


0 


S5 CAN JTAG 


Enable Canister Board JTAG Chain TMS 


Required to select the JTAG chain 


RE1 


0 


S5 NMI S5 


NMI card is special slot 5 (IOP) 


Toggle to NMI IOP in slot 5 


RE2 


0 


S2 FAN HI 


Canister fan speed to high (Assert Hi) 


Assert on any Canister fan failure 
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Wire Service Remote Interface (System Type ID S6) Processor ID 11 



Pin 


Type 


N3me 


Function 


Notes 


PAH 




OO "OiN rvl 


Serial Number information for Remote Interface 




PA 1 


X 








RA9 


X 








DA'S 

rv\o 


X 








DAM 


X 








DAC 

rvrw 


X 








PRO 




eft MnncKii nTR 

oD iviVJL/tivi U 1 r\ 


Modem Signal (Data Terminal Ready) 




RR1 


i 

i 


OO ML/L/CM Uor\ 


ivioaein oiynai luaia oei Keaoyj 




RR9 


i 




iviouem oiynai garner ueiecij 




RR^ 


i 
i 


OO IVIVJl^CIVI r\l 
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Wire Service Network Memory Map 

This section defines the Wire Service Network Memory Map for the first Raptor system. Its purpose 
is to identify all Wire Service addressable entities and describe their function and any special 
information about them. 

In the following table: 

Name is the official symbolic name for the Wire Service entity. 

Type is the data type for the entity from the data type described previously. 

PID is the processor ID (hexadecimal) of the Wire Service Processor where the data resides. 

Note: Canister Wire Service PID is determined by adding 0x20 to the canister addresss on 

S5_CAN_A[0-2]. 
Description is a short narrative on the function of the entity. 
Notes describe any other special information or actions involving the entity 



Name 


Type 


PID 


Description 


Notes 


WS_DESC_Pn 


STRING 


Any 


Wire Service 

Processor 

Type/Description 




WS_REV_Pn 


STRING 


Any 


Wire Service Software 
Revision/Date Info 




WS1SB_FAN_HI 


BIT 


03 


^ System Board Fans HI* 


Controls S1_TAN_HI. Set on 0->1 " 
transition of WS_S B_F AN_LE D . Cleared • 
by other software 


WS_SB_FAN_LED 


BIT 


03 


System Board Fan 
Fault LED 


Controls S1_SBFANJ_ED. It is set 
whenever any WS_SB_F AN FAULT is 
non-zero. Log 0->1 transition 


WS_SB_BUSCORE 


BYTE 


03 


System Board 
BUS/CORE speed 
ratio to use on reset 


Value is asserted on S1_BC_DS[0-3] 
unless reading DIMM types. Set to 0 on 
power on. 


WS_SYS_LCD1 


STRING 


03 


Value to display on 
LCD line 1 


For a Nx2 display wher LCD1 is the top 
line and LCD2 is the bottom line. No 
wrapping occurs from one line to the 
other. Manipulates S1 LCD D[0-7], 
S1 LCD RS, S1 LCD ENA, 
S1_LCD_RW 


WS_SYSJ_CD2 


STRING 


03 


Value to display on 
LCD line 2 


WS_SB_FAN_DATA 


STRING 


03 


System Board Fan 
speed data in fan 
number order 


Approximately every second a fan is 
selected by S1_FAN_SEL[0-2] and 
monitored via S1_FAN_TP driving a 
counter for a known period of time. The 
counter is then loaded into the 
appropriate fan speed, if 
WS_SB_FAN_Hl is not set then the 
speed is compared against 
WS SB FAN LOLIM. If fan is slow set 
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appropriate bit in WS_SB_F AN FAULT 
otherwise clear it 


WS_S B_F AN F AU LT 


BYTE 


03 


System Board Fan 
fault bits 


Bit 0 = Fan1. bit 1 = Fan2, etc. A non- 
zero byte value implies at least one fan 
faulted. 


WS_SB_FAN_LOLIM 


BYTE 


03 


Fan speed low speed 
fault limit 


Set to ??? on power on 


WS_SB_DIMM_TYPE 


STRING 


03 


The type of DIMM in 
each DIMM socket as 
a 16 byte string 


When read asserts value of 0..15 on 
S1_BC_DS[0-3] and then returns value of 
S1_DIMM_D[0-7] for each value. 


WS_SB_FLASH_ENA 


BIT 


04 


Indicates FLASH ROW 
write enabled 


Set/Cleared by denounced 0->1 
transition of S2FLASH_SW. 
Controls state of S2 FLASH WE and 
S2_FLASH_LED. 


WS_SB_FRU_FAULT 


BIT 


04 


Indicates the FRU 
status 


At power on starts at 1 . Controls 
S2_SBFLT_LED[0-1] for bicolor LED 
colors 0=Green 1= Amber, Cleared by 
other software 


WS_SYS_OVERTEMP 


BIT 


04 


Indicates Overtemp 
fault , 9 


At power on is set. Controls 
S2_OVRTMP_LED. Controlled by wire - 
service backplane processor. 


WS_SB_JTAG 


BIT 


04 


Enables JTAG chain 
on system board 


Clear at power on. Controls 
S2_SB_JTAG 


WS_SB_CPU_PRES 


' BYTE 


04 


CPU Presence bits 
(LSB = CPU1) 


Assemble from S2_PRES_CPU[1-4] 


WS_SB_CPU_ERR 


BYTE 


04 


CPU Error bits 
(LSB = CPU1) 


Assemble from S2_ERROR_CPU[1-4] 


WS_SB_CPU_TEMP 


BYTE 


04 


CPU Thermal fault bits 
(LSB = CPU1) 


Assemble from S2_TEMP_CPU[1-4] 


WS_SB_CPU_POK 


BYTE 


04 


CPU Power OK 
(LSB = CPU1) 


Assemble from S2_POK_CPU[1-4] 


WS_NMI_MASK 


BYTE 


04 


CPU NMI processor 
mask (LSB=CPU1) 


Defaults to all ones on power up 


WS_NMI_REQ 


BIT 


04 


NMI Request bit 


When set pulse S2_NMI_CPUn 
corresponding to each bit set in 
WS_NMI_MASK. Then clear request bit. 
Log Action 


WS_SYSFAULT 


BIT 


04 


System Fault 
Summary 


This bit is set if any faults detected in the 
system. Controls S2_SYSFLT_LED 
Bits scanned WS SP CPU FAULT, 
WS_SB_FRU_FAULT ( other faults?) 


WS_SB_CPU_FAULT 


BIT 


04 


CPU Fault Summary 


This bit is set if (( WS SB CPU ERR | 

WS SB CPU TEMP | 

-WS SB CPU POK ) & 

-WS SB CPU PRES)!=0. Log 0->1 
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* 


transition with CPU bytes. 


RP P^V 

WO D i r O V 


BYTE 


02 


Analog Measure of +5 
volt main supply 


read from S4_VOLTS_P5v 


WS_BP_P3V 


BYTE 


02 


Analog Measure of 
+3.3 volt main supply 


read from S4_VOLTS_P3v 


WS_BP_P12V 


BYTE 


02 


Analog Measure of 
+12 volt main supply 


read from S4_VOLTS_P12v 


WS_BP_P5V 


BYTE 


02 


Analog Measure of -12 
volt main supply 


read from S4_VOLTS_N12V 


WS_SYS_CAN_PRES 


BYTE 


02 


Presence bits for 

canisters 

(LSB=1,MSB=8) 


controlled by S4_PSN_CAN[1-8]. A 
previous value byte needs to be 
maintained so canister transitions can be ' 
recognized. Previous value initialized to 
zero. Periodic monitor scans for new 
canisters. When new canister is 
recognized read full serial data and store 
in WS_SYS_CAN_SERIALn then log and , 
send event 


WS_SYS_PS_PRES 


BYTE 


02 


Presence bits for 
power supplies 
(LSB=1,MSB=3) 


controlled by S4_PSN_PS[1-3]. A 
previous value byte needs to be 
maintained so power supply transitions . 
can be recognized. Previous value 
initialized to zero. Periodic monitor" scans 
for new power supplies. When new power- - 
supply is recognized read full serial data 
and store in WS_SYS_PS_SERIALn then 
log and send event 


WS_SYS_PS_ACOK 


BYTE 


02 


Power supply ACOK 
status 

(LSB=1, MSB=3) 


controlled by S4_ACOK_PS[1-3]. A 
previous value byte needs to be 
maintained so power supply transitions 
can be recognized. Previous value 
initialized to zero. Periodic monitor scans 
for changes is ACOK and sends events . 


WS_SYS_PS_DCOK 


BYTE 


02 


Power supply DCOK 
status 

(LSB=1,MSB=3) 


controlled by S4_DCOK_PS[1-3]. A 
previous value byte needs to be 
maintained so power supply transitions 
can be recognized. Previous value 
initialized to zero. Periodic monitor scans 
for changes is ACOK and sends events 


WS_SYS_BPJTYPE 


BYTE 


02 


Type of system 
backplane currently 
only two types Type 
0= 4 canister (small) 
and Type 1 = 8 canister 
(large) 


controlled by S4_BP_TYPE 


WS_SYS_TEMP_DATA 


STRING 


02 


Temperatures of all 
sensors on 
temperature bus in 
address order 


controlled by reading Dallas temperature 
transducers connected to serial bus on 
S4_TEMP_SDA and S4_TEMP_SCL 
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WS_SYS_TEMP_WARN 


BYTE 


02 


Warning temperature. 
Initialized to ??? 


If any WS_SYS_TEMP_xxn exceeds this 
value, log, send event, set 
WS_SYS_OVERTEMP 


WS_SYS_TEMP_SHUT 


BYTE 


02 


Shutdown 

temperature. Initialized 
to??? 


If any WS_SYS TEMP_xxn exceeds this 
value, log and clear WS_SYS_POWER 


WS_SYS_REQ_POWER 


BIT 


02 


Set to request main 
power on 




WS_SYS_POWER 


BIT 


02 


Controls system 
master power 
S4_POWER_ON 


When this bit is set 0->1 set 
S4_POWER ON, WS SYS RUN = 0, 
WS_SYS_RSTIMER = 5 and log, When 
this bit is cleared clear S4_POWER_ON 
and log. 


WS_SYS_RSTIMER 


BYTE 


02 


Used to delay \ 
reset/run until powen 
stabilized ^/ 


Counts down to 0 at 10 counts per 
-second .4A/hen^^transitic>o sets 
WS_SYS_RUN. 


WS_SYS_WDOG 


BYTE 


02 


System watchdog 
timer 


Counts down to 0 at 10 countsper secong 
When 1->0 transition takes action(s) . . 
specified by WS WDOG RESET and 
WS_WDOG_CALLOUT. 


WS_SYS_RUN 


BIT 


02 


Controls the system 
halt/run line 
S1_OK_TO_RUN. 


If this bit is cleared, clear 
S1_OK_TO_RUN and log. 
If this bit is set, set S1_OK_TO_RUN and 
log. • 


WS_CAN_POWER 


BIT 


2x 


Controls canister PCI 
slot power 


When set then set . , 
S5_PJ5V_ENA[1..4],S5_P12V_ENA in that 
order with* small (abtfut 1 ms) delay 
between each, then log. & 
When cleared then clear S5 P12V ENA, 
SS^PSV.ENAfl^] then log 


WS_CAN_PCI_PRESENT 


BYTE 


2x 


Reflects PCI card 
slot[1..4] presence 
indicator pins 
( MSB to LSB) 
48,4A,3B,3A,2e,2A,18 
,1A 


Reflects data from 
S5_PRSNT_S[1..4][A/B] 


WS_CAN_S5_PRESENT 


BIT 


2x 


Indicates the presence 
of something in slot 5 


Reflects S5_PRSNT_S5 


WS_CAN_S5_SMART 


BIT 


2x 


Indicates something 
other than a passive 
. board in slot 5 


On power up attempt to read Dallas serial 
number chip using S5_PSN_S5. If 
present set this bit and read full serial 
data and store in 
WS_SYS_CAN_IOP_SERIALn 


WS_CAN_FAN_HI 


BIT 


2x 


Canister Fans HI 


Controls S1_FAN_H1. Set on 0->1 
transition of WS_SB_FAN_LED. Cleared 
by other software 


WS_CAN_FANJ_ED 


BIT 


2x 


Canister Fan Fault 


Controls S5_CANFAN_LED. It is set 
whenever any WS_C AN_F AN F AU LTn is 
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LED 


set. Log 0->1 transition 


WS_CAN_F AN FAULT 


BYTE 


03 


Canister. Fan Fault Bits 




WS_CAN_FAN_DATA 


STRING 


2x 


Canister Fan speed 
data 


Approximately every second a fan is 
selected by S5_FAN_SEL0 and 
monitored via S5_FAN_TP driving a 
counter for a known period of time. The 
counter is then loaded into the 
appropriate fan speed. If 
WS_CAN_FAN_HI is not set then the 
speed is compared against 
WS CAN FAN LOLIM. If fan is slow set 
appropriate WS_C AN_F AN F AU LTn 
otherwise clear it 


WS_CAN_FAN_LOLIM 


BYTE 


2x 


Fan low speed fault 
limit 


Set to equivalent of xxx RPM on power on 


WS_CAN_JTAG_ENA 


BIT 


2x 


Enable JTAG JMS 
chain for canister 


Copy set value to S5_CAN_JTAG 


WS_CAN_NM!_S5 


BIT 


2x 


NMI card in slot 5 


when set, pulse S2_NMI_S5 


WS_RI_CD 


BIT 


11 


Status of Remote Port 
Modem CD 


Follows S6_MODEM_CD 


WS_RI_DTR 


BIT 


11 


State of Remote Port 
Modem DTR 


Controls S6_MODEM_DTR 


WS._RI_DSR 


BIT 


11 


• Status of Remote Port 
Modem DSR 


Follows S6_MODEM_DSR 


WS_RI_RTS 


BIT 


11 


Status of Remote Port 
Modem RTS 


Controls S6 MODEM_RTS 


WS_RI_CTS 


BIT 


11 


Status of Remote Port .. 
Modem CTS 


Follows S6_MODEM_CTS 


WS_RI_CALLOUT 


BYTE 


11 


Controls Call out Script 
activation 


If written to it initiates Call out sequence 
programmed in WS_SYS XALL_SCRIPT 
passing value as argument to script. Log 
it 

( Format of Script Programs TBD ) 


WS_RI_EVENTS 


EVENT 


11 


Remote Interface 
Event BitVecctor 


See Event Data type description in prior 
section- 


WS_S1_EVENTS 


EVENT 


10 


System Interface 
Event BitVector 


See Event Data type description in prior 
section. 


WS_SYSJ_OG 


LOG 


01 


System Log 


The system log kept in NVRAM ( See 
LOG data type in previous section ) 


WS_SYS_SCREEN 


SCREEN 


01 


System Screen 


A copy of the most recent character mode 
screen from the system video display ( 
See SCREEN data type in previous 
section ) 



NctFRAME CONFIDENTIAL DOCUMENT 



Page 29 



Raptor Wire Service Architecture 



WS_SYS_B00TFLAG1 


BYTE 


01 


System Boot Flag 1 


Used by BIOS, Diagnostics and 
Operating systems to control behavior. 
Values defined by those entities. 


WS_SYS_B00TFLAG2 


BYTE 


01 


System Boot Flag 2 


WS_SYS_B00TFLAG3 


BYTE 


01 


System Boot Flag 3 


WS_SYS_B00TFLAG4 


BYTE 


01 


System Boot Flag 4 


WS_SYS_BOOTDEVS 


STRING 


01 


System Boot Devices 


Used by BIOS to determine boot device 


WS_SYS_SB_SERIAL 


STRING 


01 


Last known System 
Board serial data 




WS_SYS_BP_SERIAL 


STRING 


01 


Last known Back 
Plane serial data 




WS_SYS_RI_SERlAL 


STRING 


01 


Last known Remote 
Interface serial data 




WS_SYS_CAN_SERIAL[1-8] 


STRING 


01 


Last known Canister 
[1-8] Serial data 


May be zero length if no canister ever 
seen 


WS_SYSJ0P_SERIAL[1-8] 


STRING 


01 


Last known I OP in 
Canister [1-8] Serial 
data 


May be zero length if no canister ever 
seen or current canister has no IOP 


WS_PASSWORD 


STRING 


01 


The access password 
for Wire Service 


Used only for remote access 


WS_WCX)G_RESET 


BIT 


01 


This is a bit controlling 
system on a wathcdog 
timeout. 


This bit is queried on a watch dog 
timeout. If it is 1 a system reset takes 
place. 


WS_WDOG_CALLOUT 


BIT 


01 


This is a bit controlling 
callout on a wathcdog 
timeout. 


This bit isqueried on a watch dog timeout 
If it is a 1 a callouf is initial ted. 


WS_POWERUP_HOLD 


BIT 


01 


The mode controls 
action of system on 
A/C power available 


If this bit is clear, when A/C power first 
becomes available the system will power 
on. If bit is set the system will not 
powerup automatically. 


WS_CALLOUT_SCRIPT 


STRING 


01 


The callout script for 
remote notification 


Used for remote access 


WS_SI_QUEUE 


QUEUE 


01 


Queue of data going to 
System Interface 


See Queue data type in previous section 


WS_RI_QUEUE 


QUEUE 


01 


Queue of data going to 
Remote Interface 


See Queue data type in previous section 


WS_SYS_XDATA 


BYTE 
ARRAY 


01 


Byte Array for storage 
of arbitrary external 
data in NVRAM 


Wire Service just maintains this data area 
and is unaware of the meaning of any 
data stored in it. 


WS_SYS_XDATA_KBYTES 


BYTE 


01 


Size of the 
WS_SYS_XDATA in 
kilobytes 


Necessary for memory management of 
the data area 
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WS_NVRAM_RESET 


BYTE 


01 


Trigger to reset 


When the value 0x5a is written to this 








NVRAM Data 


variable, all of NVRAM is reinitialized or 










cleared. This byte should be that last 










cleared to indicate the reinitialization is 










complete. 
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Wire Services Processor Functions/Requirements 

The previous section either states or directly implies many monitoring, control and feedback 
operations carried out by the different wire service processors. In addition the following functions or 
actions must be implemented: 

• Monitor and debounce all switches. All switches are considered to be momentary contact type and 
all actions are taken on the 0 to 1 transition. All 0 to 1 transitions are logged. 

S4_PO WER_S W -Toggle the state of WS_S YS_POWER. 

S1_RESET_SW - If WS_SYS_RUN is set, clear WS_SYS_RUN. Next if WS_SYS_POWER is 
set, set WS_SYS_RSTIMER to 5. 

S2_FL ASH_S W - Toggle the state of WS_SBJFLASH_ENA. 
S2_NMI_SW - Set WS_NMI_REQ. 

• Startup process when backplane Wire Service processors are first powered up: 

1) If S4_POWER_SW is depressed when starting and for at least 5 seconds after, this causes Wire 
Service backplane processor to reinitialize the contents of the NVRAM by writing a special-value 
of 0x5a to WS_NVRAM_RESET and then reading WS_NVRAM_RESET until it returns 0. 

2) Read system board serial information on S4_PSN_SB and store it in WS_SYS_SB_SERIAL 
and backplane board serial on S4_PSN_BP and store it in WS_SYS_BP_SERIAL using the 
Dallas one wire serial protocol.. 

3) If WS_SYS_PS_ACOK is not zero, then check WS_POWERUP_HOLD. 

4) If WS JPO WERUPJHOLD is clear then set WS_S YS_PO WER. 

• Power on process when WS_SYS_POWER is set: 

1) Log power on requested. 

2) Log WS_SYS_TEMP_SHUT, WS_SYS_TEMP_WARN, WS_SYS_TEMP_DATA. 

3) If WS_S YS_OVERTEMP is not set, continue with next step otherwise stop. 

4) Set S4_POWER_ON. 

5) Set WS_SYS_RSTIMER to 5 (5/10 second) and stop. 

• Power off process when WS_SYS__POWER is cleared: 

1) Log power off request. 

2) Clear WS_SYS_RUN and WS_SYS_RSTIMER. 

3) Clear S4_POWER_ON. 

• Reset sequence when WS_SYS_RSTIMER counts down from 1 to 0: 

1) If Log reset requested. 

2) Log WS_SYS_PS_PRES, WS_SYS_PS_ACOK, WS_SYS J>S_DCOK, WS_BP J>5V, 
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WS_BP_P3V, WS_BP_P12V, WSJBP_N12V. 

3) If WS_SYS_PS_DCOK not 0, continue with next step otherwise stop. 

4) Set WS_SYSJUJN. „ • 

• Temperature monitor process every several seconds: 

1) Reads all temperature sensor data into WS_SYS_TEMP_DATA 

2) Compares each WS_SYS_TEMP_DATA item to WS_SYS_TEMP_SHUT. If any data 
temperature exceeds limit and WS_SYS_POWER is set, clear WS_SYS_POWER, log 
WS_SYS_TEMP_SHUT, WS_SYS_TEMP_WARN, WS_SYS_TEMP_DATA and stop. 

3) Compares each WS_SYS_TEMP_DATA item to WS_SYS_TEMP_WARN. If any data 
temperature exceeds limit and WS_SYS_OVERTEMP is clear, set WS_SYS_OVERTEMP, send 
a TEMPERATURE event to the system and remote interfaces, log WS_S YS_TEMP_SHUT, 
WS_SYS_TEMP_WARN, WS_SYS_TEMP_DATA and stop. 

4) Otherwise if no limits are exceeded and WS_SYS_OVERTEMP is set, clear 
WS_SYS_OVERTEMP and send a TEMPERATURE event to the system and remote interfaces. 

• Monitor fault conditions for system fault and control WS_SYSFAULT_LED. (Needs further 
work on mechanism) 

• Several times per second the backplane Wire Service processor monitors S4_PSN_CANn for 
changes in presence of the canisters. Each S4_PSN_xxx line is really a Dallas one wire serial bus 
signal attached to a Dallas serial number chip. To detect the presence of a canister, a reset pulse 
must be sent by the Wire Service processor and then the canister's presence pulse must be 
detected. Unless there is a change in the presence of a canister nothing more needs to be done. If a 
change in presence is detected, the WS_S YS_CANJPRES data must be updated, a CANISTER 
event sent to the system and remote interface processors and the old and new 
WS_SYS_CAN_PRES data is logged. If the a canister was removed, nothing more needs to be 
done. If a canister was inserted, then the full serial data must ber read from the canister using the 
Dallas one wire protocol and stored in the appropriate WS_SYS_CAN_SERIALx suing. 

• Several times per second the backplane Wire Service processor monitors S4_PSN_PSn for 
changes in presence of the power supplies. Each S4_PSN_xxx line is really a Dallas one wire 
serial bus signal attached to a Dallas serial number chip. To detect the presence of a power 
supply, a reset pulse must be sent by the Wire Service processor and then the canister's presence - 
pulse must be detected. Unless there is a change in the presence of a power supply nothing more 
needs to be done. If a change in presence is detected, the WSSYSPSPRES data must be 
updated, a POWER_SUPPLY event sent to the system and remote interface processors and the 
old and new WS_SYS_PS_PRES data is logged. If the a power supply was removed, nothing 
more needs to be done. If a power supply was inserted, then the fiill serial data muss ber read from 
the power supply using the Dallas one wire protocol and stored in the appropriate 
WS_SYS_PS_SERIALx string. 

• Once per second, all Wire Service processors that have fan monitoring inputs collect data from 
the next fan in sequence to be monitored and store the fan spped data in the appropriate slot in 
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WS_xxx_FAN_DATA for that fan. If the value for the fan speed data is below 
WS_xxx_FAN_LOWLIM, the appropriate bit in WS_xxx_FAN_FAULT is set , the Wire Service 
processer ID, WS_xxx_FAN_LOWLIM, and WS_xxx_FAN_DATA are logged and 
WS_xxx_FAN_HI is set. If this occurs, the only way to reset the fan fault LED and fan speed is 
by a system or remote reset of WS_xxx_FAN_FAULT and WS_xxx_FAN_HI or power cycling 
the appropriate board. 

• The Wire Service remote interface processor on power up reads serial number data from 
S6_PSN_RI using the Dallas one wire serial protocol and stores it in WS_SYS_RI_SERIAL. 

• Events are always sent to both WS_SI_EVENTS and WS_RI_EVENTS queues with no retry if no 
processor response from target. 
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Wire Service and Raptor BIOS Interactions 

The following are items which it is known that the BIOS must implement. 

• BIOS must determine current DIMM configuration by reading WS_SB_DIMM_TYPE to 
determine DIMM types and then validating that this is an OK configuration. Also, memory can be 
initially sized this way. 

• BIOS can read WS_SB_CPU_PRES To determine which processors are present and then go out 
on the bus and somehow get the processor type and speed information to determine the correct 
BUS/CORE speed ratio. Once that is determined. The BIOS reads WS_SB_BUSCORE to 
determine the actual BUS/CORE speed ratio and if it is incorrect, write the correct one to 
WS_SB_BUSCORE, set WS_SYS_RSTMER~to 5 ( 5/10 second ), and clear WS_SYS_RUN. 
This will reset the system using the new BUS/CORE ratio. ( Note: If WS_SYS_RSTIMER is not 
set, wire service will not set WS_S YS_RUN after the BIOS clears it and the system will remain 
halted. 

• The BIOS must read WS_SYS_CAN_PRES to determine which canisters are present and then set 
WS_CAN_POWER on each canister to enable power to the PCI cards before configuring the PCI 
busses. 

• All WS_xx_FRU_LEDs are amber at power up. The BIOS sets WS_xx_FRU_LED to green when 
satisfied that the system board or canister is ok. Diagnostics may turn WS_xx_FRU_LEDs to 
amber on diagnostic failure fault. 

• The BIOS, when remote control is activated, should update the Wire Service video memory 
image from either the true character mode video memory or as it updates true video memory. The 
BIOS under the same conditions should monitor the system interface for events indicating arrival 
of keycodes in the system queue and then process those codes as normal keystrokes. This same 
mechanism can also be used for floppy/hard disk emulation. (Note: how remote control is 
activated is not yet specified ) 
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Raptor Wire Service Architecture 

Wire Service Issues Needing Resolution 

1) Does Fan Fault roll up into system fault LED? 

4) If there is a CPU thermal fault should the over temp LED turn on or system board fault LED? 

5) How much monitoring/logging should be done for CPU fault signals? 

6) What are all the conditions that turn on system fault summary LED? 

7) Are there any times that the system fault summary "must be valid? May not be valid? Response 
times? 
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Wire Service Remote Interface Serial Protocol 

The Wire Service Remote Serial protocol is used to communicate Wire Service messages across a 
serial link from a Wire Service Remote Interface processor attached to a Raptor to a Wire Service 
Remote management processor. It encapsulates Wire Services messages in a transmission envelope to 
provide error free communications and link security. * 

Wire Service Call out Script Syntax Definition 

To be specified 
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Document Revision History 

Version 0.9 - Initial Version 

Version 1 .0 - Added state diagram to system interface description 

- Completed Network Memory Map (except for precise address specification and debug ) 

- Added section detailing internal Wire Service monitoring and processes. 

- Added section for BIOS required processing 

- Added section for unresolved issues 

- Added this revision history section 

Version 1.1 - Converted to Little Endian (Intel) byte order for integers and address larger than one 
byte 

- Removed requirement for system processors to know about check bytes on messages 

- Changed system interface allocation mechanism slightly 

- Added more description and conventions for log entries 

- Changed several. Wire Service memory definitions for easier use (fan data and DIMMs) 

- Added several new Wire Service memory definitions from review and to support dial 

out 

- Added watchdog to Wire Service memory 

- Cleand up and expanded section on Wire Sendee Processing Functions 

- Added Wire Service hardware diagram 

- Added NVRAM reset mechanism 

- Added preliminary BIOS remote control description 

Version 1.2 - Changed definition and semantics of event data type from queue to bit vector 

- Split LCD display into two lines 

- Added WS_SYS_BOOTDEVS string for describing various boot device selection 
information for BIOS 
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Raptor System 

A Bird's Eye View 
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Control Diagnostic and Monitor Subsystem 

The control of Raptor is completly "Fly By Wire" - i.e. no physical switch directly controls any 
function and no indicator is directly controlled by system hardware. All such functions, refered to 
as Out Of Band functions', are controlled through a Control Diagnostic and Monitor (CDM) 
subsystem implemented by small distributed CDM processors connected on a 400 kbs I 2 C serial 
bus ( the CDM Bus ). Critical CDM components are powered by the bias power from any of the 
power supplies, which means that CDM basic CDM functions are avaiable so long as A/C power 
is avai able at the input to any of the power supplies. The CDM subsystem supervises or monitors 
the following system features: 



'Sec Glossary 
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• Power supplies - Presence, status, A/C good, Power On/Off and Output voltages. 

• Environment - Ambient and exhaust temperatures, Fan speed, speed control, Fan fault and 
Oycrtemp indicators^ 

• Processor - CPU Presence, Power OK, Overtemp and Fault, NMI control, System reset, 
Memory type/location and Bus/Core speed ratio. 

• I/O - I/O Canister insertion/removal and status indicator, PCI card presence, PCI card power 
and Smart I/O processor Out Of Band control. 

• Historical - Log of all system events, Character mode screen image, and Serial Numbers. 

Control of CDM functions is either intrinsic ( i.e. CDM components act automatically to perform 
the function, such as when a fan fails, the remaining fan has its speed increased and the fan 
failure indicator is lit) or external (i.e. the CDM subsystem gets external input requesting the 
function ). External functions can be initiated from either the system interface port by one of the 
P6 processors or through the RS232 serial CDM interface connected to the CDM External port 

The CDM subsystem remote access feature provides for remote management of the system when 
the Operating System is not available 2 . 



2 Sec section on Remote Management. 
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